The entertainment industry is in the midst of a digital revolution. Music, television, and movies are increasingly becoming digital, offering new advantages to the consumer in quality and flexibility. At the same time, since digital data can be perfectly and quickly copied, the digital revolution also comprises a threat. If consumers may freely copy entertainment content and offer that content on the Internet, the market for entertainment content may evaporate.
Content protection schemes have been devised to lessen the threat, such as Digital Rights Management (DRM) systems, Content Scrambling System (CSS) for DVD video, and Content Protection for Prerecorded Media (CPPM) for DVD audio, among many others. These systems share the following feature: the software that implements them is required to be “robust,” that is the software resists attacks by hackers, either to extract the secrets (keys) from the software or to modify the behavior of the software to get unauthorized functionality. Technologies that resist such attacks are called tamper-resistant software. Other application areas, such as finance or automotive control, may have robustness requirements. They may also have requirements to tie data to a particular processor. Such applications often employ tamper-resistant software technologies.
A common perception is that tamper-resistant software conflicts with the concept of “open source” on the premise that a hacker may more easily compromise an open source program. However, an open source content protection scheme presents definite advantages. Open standards may prevent fragmentation of the market and forestall proprietary solutions from locking out competition. In addition, an open source content protection scheme may actually help reduce the level of hacker attacks. The well-known break to the DVD video CSS scheme was enabled, in no small part, by leaks from insiders. These insiders were apparently motivated by the desire to have a DVD player on the open-source platform Linux.
Meanwhile, the Java™ language has replaced the computer language C for many applications. The Java language is implemented by converting a source program to instructions (called byte codes) of a hypothetical computer referred to as the Java Virtual Machine, or Java virtual machine (JVM™).
The Java virtual machine is not an actual hardware computer, instead it is a program that interprets the byte codes, and implements their functions on a given physical computer. This approach has given Java portability; the language is available in all types of computers and even in embedded devices such as cell phones, stereos, and TV set-top boxes.
Several companies have produced computers whose instruction set is the same as the Java virtual machine. In such a case, the Java virtual machine is real, not virtual. However, by convention, such a real computer is still called a “Java virtual machine”, a practice followed in the description of the present invention.
One approach to content protection uses a Java virtual machine to implement the robustness requirements of content protection schemes. In this approach, all secret data and algorithms are not implemented in Java; instead, they are “wired in” to the Java virtual machine itself. Furthermore, the Java virtual machine provides a “sand box” environment so that unauthorized actions are prevented. For example, when the Java virtual machine is dealing with protected content, the normal file-writing mechanism of Java is disabled. Advantageously, there is no need to verify the integrity of the Java code itself.
A trusted Java virtual machine uses a trusted dictionary to pass objects from one trusted application to another. The first trusted application places a value into the trusted dictionary; a “put” implementation of the trusted dictionary then serializes the object to a byte array and encrypts the byte array. A second trusted application obtains the value from the trusted dictionary; a “get” implementation then decrypts the byte array and deserializes the value to instantiate a clone of the original object. The clone of the original object is returned to the caller. In a similar manner, passing objects is required when performing inter-process communication (IPC) either within a single processor or between processors.
However, the first trusted application and the second trusted application may need to share the same object. In some cases, passing a clone of the object may not be acceptable. In other cases, the first trusted application and the second trusted application need to share an object that cannot be serialized. For example, objects that comprise a date, open file systems, complex state variables such as graphs, convoluted memory structure, a queue, a stack, or a stream, etc, cannot be serialized.
One conventional approach to passing an object between a first application and a second application is to send a proxy of an object. This approach is used by common object request broker architecture (CORPA), a standard for communicating between distributed objects. However, whenever the second application wishes to manipulate the object, the second application has to interact with the first application, requiring a descriptive overhead that consumes computational resources and bandwidth.
Another conventional approach addresses passing an object by means of a “handshake” between a first application and a second application. The first application and the second application agree in advance on how the second application finds the desired object. However, this approach requires the first application to give access and information to the second application that may compromise a trusted environment or other security features of the first application.
What is therefore needed is a system, a computer program product, and an associated method for sharing an object between applications that does not require serialization of the object. The need for such a solution has heretofore remained unsatisfied.